Mobile cellular communication is evolving beyond traditional voice telephony towards more sophisticated services, such as Push-To-Talk (PTT). Similar to conventional walkie-talkie communication, PTT enables mobile communication users to send a voice message to one or more recipients over a mobile phone by simply pushing a key (i.e., PTT button, etc.).
One particular version of PTT, called PoC (PTT-over-Cellular), has started to be implemented in wireless data networks such as GSM/GPRS and CDMA cellular networks. By using internet protocols (i.e., an internet protocol network), these networks can provide a packet-based data service that enables information to be sent and received across a mobile telephone network. In addition, the use of internet protocols also facilitates PoC through the use of instant connections. That is, information can be sent or received immediately as the need arises, subject to available time slots at the air interface.
PTT, including PoC-based PTT, is half-duplex. That is, all participants typically use a single frequency or channel for both transmission and reception. Either a participant speaks or listens, but not both. This is in contrast to traditional cellular communication that is full-duplex (e.g., like a regular wired phone), in which at least one channel or frequency is assigned to talk, and another separate one is assigned to listen such that both speaking and listening can occur simultaneously.
For audio/video data transmissions, PoC applications require the transmission of signaling packets using a signaling protocol, e.g., SIP (Session Initiation Protocol), and data packets using a data protocol, e.g., RTP (Real Time Protocol). SIP is a signaling protocol for Internet conferencing, telephony, presence, events notification, and instant messaging. RTP is an Internet-standard protocol for the transport of real-time data, including audio and video media. It can be used for media-on-demand as well as interactive services such as Internet telephony. RTP consists of a data and a control part. The latter is called RTCP.
As bandwidth is always a constraint in wireless applications, transmitting both signaling and data packets is problematic. For example, in a PoC environment, SIP packets generally are larger than RTP packets even after using signaling compression (SigComp). Moreover, different types of SIP packets have different size values as well. On average, a response type SIP packet is between 350 and 400 bytes while a request type packet can range from 1.2 to 1.5 kilobytes.
When a PoC application shares a single PDP (Packet Data Protocol) context for both media and for signaling, SIP signaling packets may be sent during media transmission, which can disturb RTP flow and thus degrade voice quality. Transmitting SIP packets can require significant time, which in turn creates latency of RTP packets. As a result, the receiver then hears choppy speech during the PoC conversation.
This problem will be compounded in future PoC applications. In the near future, PoC systems can involve numerous PoC Servers 10 connected to individual handsets and other user associated devices, UE 12. FIG. 1 shows a possible future system of UE 12 connected to multiple PoC Servers 10 (both participating (PPS) 14 and controlling (CPS) 16). The PPS 14 manages the media and signaling that streams from the CPS 16. The CPS 16 provides centralized media distribution and session handling among connected UE 12. The PoC Server 10 may perform a Controlling PoC Function or Participating PoC Function. The Controlling PoC Function and Participating PoC Function are different roles of the PoC Server 10, but a PoC Server 10 may perform both a Controlling PoC function and a Participating PoC function at the same time. As shown in FIG. 2, a UE 12a is connected to one or more PPS 14 which in turn are connected to one or more CPS 16 which provide overall PoC management function for innumerable connected UE 12b. 
Problems arise in this system setup because the PoC Servers 10 are not connected to each other. A user can be in a PoC session over one PPS 14a as other PPS 14b are trying to send the UE 12a an Invite request to join another PoC session. Conflicts between data and signal packets can result in poor talk burst quality during an existing PTT session when the new invitation comes in to UE 12a. 
Current PoC standards, which call for compression, do not adequately address this problem. PoC may be implemented over a variety of access networks, including GPRS according to 3GPP Release 97/98, EGPRS according to 3GPP Release 99 or later releases, and UMTS according to Release 99 or later releases. For these networks, a PoC implementation preferably follows these recommendations:                The PoC implementation should work in an access network that delivers a throughput of 7.2 kbps or more.        The QoS profile parameters should be set such that the RLC uses an acknowledged mode of operation.        If streaming traffic class is supported by the access network, PoC should use this traffic class for the exchange of RTP/RTCP data.        The POC client should support AMR 5.15 as the mandatory and default codec, with optional support of AMR 4.75 being desirable. The support of any other AMR codec is at design discretion.        The AMR payload format should use the octet-aligned mode (byte aligned) without interleaving and without CRCs.        
If traffic class streaming can be supported in the GPRS network, then an interactive traffic class PDP context is preferably used for SIP and HTTP signaling; and a streaming traffic class PDP context is preferably used for the RTP/RTCP packets. If streaming is not available, then either two interactive PDP contexts may be used (one interactive PDP context intended for PoC signaling and one interactive PDP context for RTP media), or a single PDP context may be used for both PoC signaling and RTP media.
In order to ensure optimal service quality for PoC in GPRS networks, the QoS profile parameter values are carefully selected by the UE in PDP context activation requests. Since 3GPP Release 97/98 compliant networks do not provide support for a streaming traffic class, a QoS profile of a single PDP context may be shared between PoC signaling and media flows.
If using a dedicated PDP context for RTP/RTCP media, this context should be set up before or at the time of the first talk session. The RTCP traffic may be transported on the same PDP context as the SIP/HTTP signaling.
When a single PDP context is shared between media and signaling, PoC proposes some QoS parameter settings that express a compromise between satisfying different transport requirements of signaling and voice media flows to ensure the best possible overall service quality for PoC. But using traffic class streaming does not fully solve the problem. The GPRS network cannot differentiate among the various types of frames within RTP packets and the stability of multiple streams cannot be guaranteed. Also, actual bandwidth in the GPRS network can fluctuate, making scheduling of packets important to ensure a good user experience.
Since even the best GPRS network is not able to guarantee any throughput to the UE, the PoC service quality can only be ensured if the radio access network is appropriately dimensioned. The following configurative means are available to improve the performance of the PoC service:                Radio channels can be assigned exclusively to PS data traffic (to avoid pre-emption by CS flows).        The maximal number of PS users multiplexed on the same timeslot (separate for UL and DL) can be limited.        The weight assigned to the priority level (related to the Precedence Class parameter value) of the PoC flow can be augmented.        UDP/IP header compression (RFC2507) can be configured to reduce the required radio link capacity.        
If the underlying access network supports traffic class streaming, the secondary PDP context is to be-used for the media (voice) flows of the PoC application. In addition, the following configurative means are available to improve the performance of the PoC service:                UDP/IP header compression (RFC2507) or RTP/UDP/IP header compression (RFC3095) can be configured to reduce the required radio link capacity.        Delayed release of DL Temporary Block Flows (TBFs) and Extended TBF Mode in UL (available for 3GPP Release 4 compliant networks only) can be configured to preserve the TBF over a longer period of time.        
In sum, where PTT applications operate in a limited bandwidth environment such as cellular networks, when signaling packets are transmitted at the same time as data packets, voice quality is diminished resulting in a poor user experience regardless of the type of packet compression in use. The present invention addresses the problem through effective scheduling of data and signaling packets for PTT applications, such as PoC, operating in limited bandwidth environments.
PoC is discussed in greater detail in the following technical specifications which are incorporated by reference: Push-to-talk over Cellular (PoC), Architecture, PoC Release 2.0, V2.0.8 (2004-06); Push-to-talk over Cellular (PoC), Signaling Flows—UE to Network Interface (UNI), PoC Release 2.0, V2.0.6 (2004-06); and Push-to-talk over Cellular (PoC) User Plane, Transport Protocols, PoC Release 2.0, V2.0.8 (2004-06). Of note, Release 1.0 is also available from the PoC Consortium as well as an upcoming PoC standard from Open Mobile Alliance (OMA). All of these are generally considered native PoC standards. Subsequently, a UE (user equipment), such as a PoC enabled cellular phone, supporting either of these standards is called a native PoC client (or non-DVM client).